فراتر از بوق: تسلط بر پاسخ به حادثه با اتوماسیون سیستم هشدار

این سناریو برای متخصصان فنی در سراسر جهان آشنا است: صدای نافذ یک هشدار در دل شب. این یک آژیر دیجیتالی است که شما را از خواب بیدار می کند و خواستار توجه فوری است. سال ها، عملکرد اصلی یک سیستم هشدار فقط این بود - هشدار دادن. این یک پیجر پیچیده بود که به طور تخصصی طراحی شده بود تا انسان مناسب را برای رفع مشکل پیدا کند. اما در سیستم های پیچیده، توزیع شده و در مقیاس جهانی امروزی، بیدار کردن یک نفر به تنهایی کافی نیست. هزینه مداخله دستی، که با زمان خرابی، از دست دادن درآمد و فرسودگی شغلی انسان اندازه گیری می شود، بسیار زیاد است.

هشدار مدرن تکامل یافته است. دیگر فقط یک سیستم اطلاع رسانی نیست. این سیستم عصبی مرکزی برای پاسخ خودکار به حادثه است. این نقطه شروع برای یک آبشار از اقدامات هوشمندانه است که برای تشخیص، اصلاح و حل مشکلات قبل از مداخله یک انسان طراحی شده اند. این راهنما برای مهندسان قابلیت اطمینان سایت (SRE)، متخصصان DevOps، تیم های عملیات IT و رهبران مهندسی است که آماده فراتر رفتن از بوق هستند. ما اصول، شیوه ها و ابزارهای مورد نیاز برای تبدیل استراتژی هشدار خود از یک مدل اطلاع رسانی واکنشی به یک موتور حل خودکار و فعال را بررسی خواهیم کرد.

تکامل هشدار: از پینگ های ساده تا ارکستراسیون هوشمند

برای درک اینکه به کجا می رویم، درک اینکه کجا بوده ایم ضروری است. سیر تکاملی سیستم های هشدار، پیچیدگی فزاینده معماری های نرم افزاری ما را منعکس می کند.

فاز 1: دوران دستی - "یک مشکلی وجود دارد!"

در روزهای اولیه فناوری اطلاعات، نظارت ابتدایی بود. یک اسکریپت ممکن است بررسی کند که آیا استفاده از CPU یک سرور از آستانه 90٪ فراتر رفته است یا خیر و اگر چنین است، یک ایمیل به یک لیست توزیع ارسال کند. هیچ زمان‌بندی آنکال، هیچ تشدید و هیچ زمینه ای وجود نداشت. هشدار یک بیانیه ساده و اغلب مبهم از واقعیت بود. پاسخ کاملاً دستی بود: وارد شوید، تحقیق کنید و رفع کنید. این رویکرد منجر به زمان‌های حل طولانی (MTTR - میانگین زمان برای حل) شد و به دانش عمیق سیستم از هر اپراتور نیاز داشت.

فاز 2: دوران اطلاع رسانی - "بیدار شو، انسان!"

ظهور پلتفرم‌های تخصصی هشدار مانند PagerDuty، Opsgenie (اکنون Jira Service Management) و VictorOps (اکنون Splunk On-Call) یک جهش بزرگ رو به جلو را رقم زد. این ابزارها، عمل اطلاع‌رسانی را حرفه‌ای کردند. آنها مفاهیم مهمی را معرفی کردند که اکنون به یک استاندارد صنعتی تبدیل شده‌اند:

• زمان‌بندی‌های آنکال: اطمینان از اینکه فرد مناسب در زمان مناسب، در هر کجای دنیا، مطلع می‌شود.
• سیاست‌های تشدید: اگر مهندس آنکال اصلی، یک هشدار را تایید نکند، به طور خودکار به یک مخاطب ثانویه یا یک مدیر تشدید می‌شود.
• اعلان‌های چند کاناله: دستیابی به مهندسان از طریق اعلان‌های فشاری، پیامک، تماس تلفنی و برنامه‌های چت برای اطمینان از دیده شدن هشدار.

این دوران در مورد به حداقل رساندن میانگین زمان تایید (MTTA) بود. تمرکز بر این بود که به طور قابل اعتماد و سریع، یک انسان را با مشکل درگیر کرد. در حالی که این یک پیشرفت عظیم بود، اما هنوز کل بار تشخیص و اصلاح را بر دوش مهندس آنکال قرار می‌داد و منجر به خستگی و فرسودگی شغلی می‌شد.

فاز 3: دوران اتوماسیون - "اجازه دهید سیستم آن را مدیریت کند."

این وضعیت فعلی و آینده هشدار است. هشدار دیگر پایان مسئولیت ماشین نیست. این یک رویداد است که یک گردش کار خودکار و از پیش تعریف شده را فعال می کند. هدف، کاهش یا حذف نیاز به مداخله انسانی برای یک دسته در حال رشد از حوادث رایج است. این رویکرد به طور مستقیم کاهش میانگین زمان برای حل (MTTR) را با توانمندسازی سیستم برای تعمیر خود هدف قرار می‌دهد. این رویکرد، پاسخ به حادثه را نه به عنوان یک هنر دستی، بلکه به عنوان یک مسئله مهندسی تلقی می‌کند که باید با کد، اتوماسیون و سیستم‌های هوشمند حل شود.

اصول اصلی اتوماسیون پاسخ به حادثه

ایجاد یک استراتژی اتوماسیون قوی، نیازمند تغییر در طرز فکر است. این در مورد اتصال کورکورانه اسکریپت ها به هشدارها نیست. این در مورد یک رویکرد اصولی برای ساختن یک سیستم قابل اعتماد، معتبر و مقیاس پذیر است.

اصل 1: فقط هشدارهای قابل اقدام

قبل از اینکه بتوانید یک پاسخ را خودکار کنید، باید اطمینان حاصل کنید که سیگنال معنی دار است. بزرگترین آفت در تیم‌های آنکال، خستگی هشدار است - حالتی از حساسیت‌زدایی ناشی از یک رگبار مداوم از هشدارهای کم ارزش و غیرقابل اقدام. اگر یک هشدار فعال شود و پاسخ صحیح این باشد که آن را نادیده بگیریم، این یک هشدار نیست. این یک نویز است.

هر هشدار در سیستم شما باید آزمون "خب که چی؟" را پشت سر بگذارد. وقتی یک هشدار فعال می‌شود، چه اقدام خاصی باید انجام شود؟ اگر پاسخ مبهم است یا "من باید 20 دقیقه تحقیق کنم تا بفهمم"، هشدار نیاز به اصلاح دارد. یک هشدار CPU بالا اغلب نویز است. یک هشدار "تأخیر P99 رو به روی کاربر، از هدف سطح خدمات (SLO) خود برای 5 دقیقه تجاوز کرده است" یک سیگنال واضح از تأثیر کاربر است و نیاز به اقدام دارد.

اصل 2: ران بوک به عنوان کد

دهه‌ها، ران بوک‌ها اسناد استاتیک بودند - فایل‌های متنی یا صفحات ویکی که مراحل حل یک مشکل را شرح می‌دادند. اینها اغلب قدیمی، مبهم و مستعد خطای انسانی بودند، به ویژه تحت فشار یک قطعی. رویکرد مدرن، ران بوک به عنوان کد است. رویه های پاسخ به حادثه شما باید در اسکریپت های اجرایی و فایل های پیکربندی تعریف شوند، که در یک سیستم کنترل نسخه مانند Git ذخیره می شوند.

این رویکرد مزایای زیادی را ارائه می دهد:

• سازگاری: فرآیند اصلاح هر بار به طور یکسان اجرا می شود، صرف نظر از اینکه چه کسی آنکال است یا سطح تجربه آنها چقدر است. این برای تیم های جهانی که در مناطق مختلف فعالیت می کنند، بسیار مهم است.
• قابلیت آزمایش: می توانید برای اسکریپت های اتوماسیون خود، تست بنویسید و آنها را در محیط های استیجینگ قبل از استقرار آنها در محیط عملیاتی، اعتبارسنجی کنید.
• بررسی همتا: تغییرات در رویه های پاسخ، همانند کد برنامه، از طریق فرآیند بررسی کد می گذرد و کیفیت را بهبود می بخشد و دانش را به اشتراک می گذارد.
• قابلیت حسابرسی: شما یک تاریخچه واضح و دارای نسخه از هر تغییری که در منطق پاسخ به حادثه خود ایجاد کرده اید، دارید.

اصل 3: اتوماسیون چند لایه و انسان در حلقه

اتوماسیون یک سوئیچ همه یا هیچ نیست. یک رویکرد مرحله‌ای و چند لایه، اعتماد ایجاد می‌کند و خطر را به حداقل می‌رساند.

• لایه 1: اتوماسیون تشخیصی. این امن‌ترین و ارزشمندترین مکان برای شروع است. هنگامی که یک هشدار فعال می شود، اولین اقدام خودکار، جمع آوری اطلاعات است. این می تواند شامل واکشی گزارش ها از سرویس آسیب دیده، اجرای دستور `kubectl describe pod`، پرس و جو از یک پایگاه داده برای آمار اتصال، یا کشیدن معیارها از یک داشبورد خاص باشد. این اطلاعات سپس به طور خودکار به هشدار یا تیکت حادثه پیوست می شود. این به تنهایی می تواند 5-10 دقیقه جمع آوری اطلاعات دیوانه وار را در شروع هر حادثه برای مهندس آنکال صرفه جویی کند.
• لایه 2: اصلاحات پیشنهادی. گام بعدی این است که یک اقدام از پیش تأیید شده را به مهندس آنکال ارائه دهید. به جای اینکه سیستم به تنهایی اقدام کند، یک دکمه در هشدار (به عنوان مثال، در Slack یا برنامه ابزار هشدار) نشان می دهد که می گوید "راه اندازی مجدد سرویس" یا "پایگاه داده Failover". انسان هنوز تصمیم گیرنده نهایی است، اما خود عمل یک فرآیند یک کلیکی و خودکار است.
• لایه 3: اصلاح کاملاً خودکار. این مرحله نهایی است که برای حوادث کاملاً درک شده، کم خطر و مکرر رزرو شده است. یک مثال کلاسیک، یک پاد وب سرور بدون وضعیت است که پاسخگو نیست. اگر راه اندازی مجدد پاد احتمال موفقیت بالایی داشته باشد و خطر کم عوارض جانبی منفی داشته باشد، این اقدام می تواند به طور کامل خودکار شود. سیستم خرابی را تشخیص می دهد، راه اندازی مجدد را اجرا می کند، بررسی می کند که سرویس سالم است و هشدار را حل می کند، به طور بالقوه بدون اینکه هرگز یک انسان را بیدار کند.

اصل 4: زمینه غنی پادشاه است

یک سیستم خودکار به داده های با کیفیت بالا متکی است. یک هشدار هرگز نباید فقط یک خط متن باشد. این باید یک بار اطلاعاتی غنی و آگاه به زمینه باشد که هم انسان و هم ماشین بتوانند از آن استفاده کنند. یک هشدار خوب باید شامل موارد زیر باشد:

• خلاصه ای واضح از اینکه چه چیزی خراب است و تأثیر آن بر کاربر چیست.
• پیوندهای مستقیم به داشبوردهای مشاهده مربوطه (به عنوان مثال، Grafana، Datadog) با پنجره زمانی صحیح و فیلترهایی که از قبل اعمال شده اند.
• پیوندی به پلی بوک یا ران بوک برای این هشدار خاص.
• فراداده کلیدی، مانند سرویس آسیب دیده، منطقه، خوشه و اطلاعات استقرار اخیر.
• داده های تشخیصی جمع آوری شده توسط اتوماسیون لایه 1.

این زمینه غنی به طور چشمگیری بار شناختی را بر روی مهندس کاهش می دهد و پارامترهای لازم را برای اجرای صحیح و ایمن اسکریپت های اصلاح خودکار فراهم می کند.

ایجاد خط لوله پاسخ به حادثه خودکار شما: یک راهنمای عملی

انتقال به یک مدل خودکار یک سفر است. در اینجا یک چارچوب گام به گام وجود دارد که می تواند برای هر سازمانی، صرف نظر از اندازه یا موقعیت مکانی آن، اقتباس شود.

مرحله 1: مشاهده پذیری پایه ای

شما نمی توانید آنچه را که نمی توانید ببینید خودکار کنید. یک تمرین مشاهده پذیری قوی، پیش نیاز غیرقابل مذاکره برای هر اتوماسیون معنی دار است. این بر روی سه ستون مشاهده پذیری ساخته شده است:

• معیارها: داده های عددی سری زمانی که به شما می گوید چه اتفاقی می افتد (به عنوان مثال، نرخ درخواست، درصد خطا، استفاده از CPU). ابزارهایی مانند Prometheus و خدمات مدیریت شده از ارائه دهندگانی مانند Datadog یا New Relic در اینجا رایج هستند.
• گزارش ها: سوابق دارای مهر زمانی از رویدادهای مجزا. آنها به شما می گویند چرا اتفاقی افتاده است. پلتفرم‌های متمرکز گزارش‌گیری مانند ELK Stack (Elasticsearch، Logstash، Kibana) یا Splunk ضروری هستند.
• ردیابی ها: سوابق دقیق از سفر یک درخواست از طریق یک سیستم توزیع شده. آنها برای یافتن گلوگاه ها و خرابی ها در معماری های میکروسرویس بسیار ارزشمند هستند. OpenTelemetry استاندارد جهانی در حال ظهور برای ابزار دقیق برنامه های شما برای ردیابی است.

بدون سیگنال های با کیفیت بالا از این منابع، هشدارهای شما غیرقابل اعتماد خواهند بود و اتوماسیون شما کورکورانه پرواز خواهد کرد.

مرحله 2: انتخاب و پیکربندی پلتفرم هشدار خود

پلتفرم هشدار مرکزی شما مغز عملیات شما است. هنگام ارزیابی ابزارها، فراتر از زمان‌بندی و اعلان اولیه نگاه کنید. ویژگی های کلیدی برای اتوماسیون عبارتند از:

• ادغام های غنی: چقدر خوب با ابزارهای مانیتورینگ، برنامه های چت (Slack، Microsoft Teams) و سیستم های تیکتینگ (Jira، ServiceNow) شما ادغام می شود؟
• API و Webhooks قدرتمند: شما به کنترل برنامه نویسی نیاز دارید. توانایی ارسال و دریافت وب هوک ها مکانیسم اصلی برای فعال کردن اتوماسیون خارجی است.
• قابلیت های اتوماسیون داخلی: پلتفرم های مدرن به طور مستقیم ویژگی های اتوماسیون را اضافه می کنند. اقدامات اتوماسیون PagerDuty و ادغام Rundeck، یا کانال‌های اقدام Jira Service Management (Opsgenie)، به شما امکان می‌دهند اسکریپت‌ها و ران بوک‌ها را مستقیماً از خود هشدار فعال کنید.

مرحله 3: شناسایی کاندیداهای اتوماسیون

سعی نکنید همه چیز را به طور همزمان خودکار کنید. با میوه های چیده نشده شروع کنید. تاریخچه حادثه شما یک معدن طلا از داده ها برای شناسایی نامزدهای خوب است. به حوادثی نگاه کنید که:

• مکرر: خودکار کردن چیزی که هر روز اتفاق می افتد بازده سرمایه گذاری بسیار بالاتری نسبت به خودکار کردن یک رویداد نادر دارد.
• به خوبی درک شده: علت اصلی و مراحل اصلاح باید شناخته شده و مستند شده باشد. از خودکار کردن پاسخ ها به خرابی های مرموز یا پیچیده خودداری کنید.
• کم خطر: اقدام اصلاحی باید دارای حداقل شعاع انفجار باشد. راه اندازی مجدد یک پاد مستقل و بدون وضعیت، کم خطر است. حذف یک جدول پایگاه داده تولیدی اینطور نیست.

یک پرس و جو ساده از سیستم مدیریت حادثه شما برای رایج ترین عناوین هشدار اغلب بهترین مکان برای شروع است. اگر "فضای دیسک پر است در سرور X" 50 بار در ماه گذشته ظاهر می شود و وضوح همیشه "اجرای اسکریپت تمیز کردن" است، اولین نامزد خود را پیدا کرده اید.

مرحله 4: پیاده سازی اولین ران بوک خودکار شما

بیایید یک مثال عینی را بررسی کنیم: یک پاد برنامه وب در یک خوشه Kubernetes در حال شکست در بررسی سلامت خود است.

1. محرک: یک قانون Prometheus Alertmanager تشخیص می دهد که معیار `up` برای سرویس برای بیش از دو دقیقه 0 بوده است. یک هشدار را فعال می کند.
2. مسیر: هشدار به پلتفرم هشدار مرکزی شما (به عنوان مثال، PagerDuty) ارسال می شود.
3. عملکرد - لایه 1 (تشخیص): PagerDuty هشدار را دریافت می کند. از طریق یک وب هوک، یک تابع AWS Lambda (یا یک اسکریپت روی یک پلتفرم بدون سرور به انتخاب شما) را فعال می کند. این تابع:
   • بار اطلاعات هشدار را تجزیه می کند تا نام و فضای نام پاد را بدست آورد.
   • `kubectl get pod` و `kubectl describe pod` را در برابر خوشه مربوطه اجرا می کند تا وضعیت و رویدادهای اخیر پاد را بدست آورد.
   • 100 خط آخر گزارش‌ها را از پاد ناموفق با استفاده از `kubectl logs` واکشی می‌کند.
   • تمام این اطلاعات را به عنوان یک یادداشت غنی از طریق API خود به حادثه PagerDuty اضافه می کند.
4. تصمیم گیری: در این مرحله، می توانید انتخاب کنید که مهندس آنکال را مطلع کنید، که اکنون تمام داده های تشخیصی مورد نیاز برای تصمیم گیری سریع را دارد. یا می توانید به اتوماسیون کامل ادامه دهید.
5. عملکرد - لایه 3 (اصلاح): تابع Lambda به اجرای `kubectl delete pod <pod-name>` ادامه می دهد. کنترلر ReplicaSet Kubernetes به طور خودکار یک پاد سالم جدید را برای جایگزینی آن ایجاد می کند.
6. تایید: سپس اسکریپت وارد یک حلقه می شود. 10 ثانیه صبر می کند، سپس بررسی می کند که آیا پاد جدید در حال اجرا است و بررسی آمادگی خود را گذرانده است. اگر پس از یک دقیقه موفقیت آمیز باشد، اسکریپت دوباره API PagerDuty را فرا می خواند تا به طور خودکار حادثه را حل کند. اگر مشکل پس از چندین تلاش ادامه داشت، دست از کار می کشد و بلافاصله حادثه را به یک انسان تشدید می کند و اطمینان می دهد که اتوماسیون در یک حلقه شکست گیر نمی کند.

مرحله 5: مقیاس بندی و بلوغ اتوماسیون خود

اولین موفقیت شما یک پایه برای ساختن بر روی آن است. بلوغ تمرین شما شامل موارد زیر است:

• ایجاد یک مخزن ران بوک: اسکریپت های اتوماسیون خود را در یک مخزن Git اختصاصی متمرکز کنید. این به یک کتابخانه مشترک و قابل استفاده مجدد برای کل سازمان شما تبدیل می شود.
• معرفی AIOps: با رشد شما، می توانید از هوش مصنوعی برای ابزارهای عملیات فناوری اطلاعات (AIOps) استفاده کنید. این پلتفرم ها می توانند هشدارهای مرتبط از منابع مختلف را در یک حادثه واحد همبستگی کنند، نویز را کاهش دهند و به شناسایی خودکار علت اصلی کمک کنند.
• ایجاد یک فرهنگ اتوماسیون: اتوماسیون باید یک شهروند درجه یک در فرهنگ مهندسی شما باشد. بردهای اتوماسیون را جشن بگیرید. در طول دوی سرعت برای مهندسان وقت اختصاص دهید تا نقاط درد عملیاتی خود را خودکار کنند. یک معیار کلیدی برای سلامت تیم می تواند "تعداد شب های بی خوابی" باشد، با هدف به صفر رساندن آن از طریق اتوماسیون قوی.

عنصر انسانی در یک دنیای خودکار

یک ترس رایج این است که اتوماسیون مهندسان را منسوخ می کند. واقعیت برعکس است: این نقش آنها را ارتقا می دهد.

تغییر نقش ها: از آتش نشان به مهندس پیشگیری از آتش سوزی

اتوماسیون مهندسان را از زحمت تکراری و دستی آتش نشانی رها می کند. این به آنها اجازه می دهد تا بر روی کارهای با ارزش تر و جذاب تر تمرکز کنند: بهبودهای معماری، مهندسی عملکرد، افزایش انعطاف پذیری سیستم و ساخت نسل بعدی ابزارهای اتوماسیون. شغل آنها از واکنش به خرابی ها به مهندسی سیستمی تغییر می کند که در آن خرابی ها به طور خودکار مدیریت یا به طور کامل از آنها جلوگیری می شود.

اهمیت کالبدشکافی و بهبود مستمر

هر حادثه، چه توسط انسان حل شود و چه توسط ماشین، یک فرصت یادگیری است. فرآیند کالبدشکافی بدون سرزنش مهمتر از همیشه است. تمرکز گفتگو باید شامل سوالاتی مانند موارد زیر باشد:

• آیا تشخیص خودکار ما اطلاعات درستی را ارائه داد؟
• آیا می توان این حادثه را به طور خودکار اصلاح کرد؟ اگر چنین است، مورد عمل برای ایجاد آن اتوماسیون چیست؟
• اگر اتوماسیون امتحان شد و شکست خورد، چرا شکست خورد و چگونه می توانیم آن را قوی تر کنیم؟

ایجاد اعتماد در سیستم

مهندسان فقط در طول شب می خوابند اگر به اتوماسیون اعتماد داشته باشند که کار درست را انجام می دهد. اعتماد از طریق شفافیت، قابلیت اطمینان و کنترل ایجاد می شود. این بدان معناست که هر اقدام خودکار باید به دقت ثبت شود. باید دیدن اینکه چه اسکریپتی اجرا شده، چه زمانی اجرا شده و نتیجه آن چه بوده است، آسان باشد. شروع با اتوماسیون های تشخیصی و پیشنهادی قبل از رفتن به اقدامات کاملاً مستقل به تیم این امکان را می دهد تا با گذشت زمان اعتماد به سیستم را ایجاد کنند.

ملاحظات جهانی برای اتوماسیون پاسخ به حادثه

برای سازمان های بین المللی، یک رویکرد مبتنی بر اتوماسیون مزایای منحصر به فردی را ارائه می دهد.

تحویل های پیروی از خورشید

ران بوک های خودکار و زمینه غنی، تحویل بین مهندسان آنکال در مناطق زمانی مختلف را بدون درز می کند. یک مهندس در آمریکای شمالی می تواند روز خود را با بررسی گزارشی از حوادثی که به طور خودکار در طول شب حل شده اند، در حالی که همکارانش در آسیا و اقیانوسیه آنکال بودند، شروع کند. زمینه توسط سیستم ثبت می شود، نه در یک جلسه تحویل عجولانه از دست می رود.

استانداردسازی در سراسر مناطق

اتوماسیون ثبات را اعمال می کند. یک حادثه مهم دقیقاً به همان روشی رسیدگی می شود که آیا سیستم توسط تیم در اروپا یا آمریکای جنوبی مدیریت می شود. این امر تغییرات فرآیند منطقه ای را حذف می کند و اطمینان می دهد که بهترین شیوه ها به طور جهانی اعمال می شوند، خطر را کاهش می دهند و قابلیت اطمینان را بهبود می بخشند.

محل اقامت داده ها و انطباق

هنگام طراحی اتوماسیونی که در حوزه های قضایی قانونی مختلف عمل می کند، توجه به محل اقامت داده ها و مقررات حفظ حریم خصوصی (مانند GDPR در اروپا، CCPA در کالیفرنیا و غیره) بسیار مهم است. اسکریپت های اتوماسیون شما باید به گونه ای طراحی شوند که با انطباق آگاه باشند و اطمینان حاصل کنند که داده های تشخیصی به طور نادرست از مرزها عبور نمی کنند و اقدامات برای اهداف حسابرسی ثبت می شوند.

نتیجه گیری: سفر شما به پاسخ به حادثه هوشمندتر

تکامل از یک هشدار ساده به یک گردش کار پاسخ به حادثه کاملاً خودکار، یک سفر تحول آفرین است. این یک تغییر از فرهنگ آتش نشانی واکنشی به یک فرهنگ مهندسی فعال است. با پذیرش اصول هشدار قابل اقدام، رفتار با ران بوک ها به عنوان کد و اتخاذ یک رویکرد چند لایه و ایجاد اعتماد در پیاده سازی، می توانید یک تجربه آنکال انعطاف پذیرتر، کارآمدتر و انسانی تر ایجاد کنید.

هدف این نیست که انسان را از حلقه حذف کنیم، بلکه ارتقای نقش آنهاست - توانمندسازی آنها برای کار بر روی چالش برانگیزترین مشکلات با خودکار کردن کارهای پیش پا افتاده. معیار نهایی موفقیت برای سیستم هشدار و اتوماسیون شما یک شب آرام است. این اطمینان است که سیستمی که ساخته اید قادر به مراقبت از خود است و به تیم شما اجازه می دهد تا انرژی خود را بر ساختن آینده متمرکز کنند. سفر شما از امروز شروع می شود: یک کار دستی و مکرر را در فرآیند پاسخ به حادثه خود شناسایی کنید و این سوال ساده را بپرسید: "چگونه می توانیم این را خودکار کنیم؟"